Description

• Normalize birthdate type of an existing Patient record from datetime.time to str upon match evaluation, before comparing with birthdate of an incoming Patient record.

Related Issues

• Closes Duplicate patients with multiple last names not matching #17

Additional Notes

In the future, we should normalize birthdate type elsewhere, and only once. Currently, this datetime.time to str type conversion happens several places. This can be done more DRYly, and any data transformations/normalizations of blocking or matching fields should be done separately from where blocking or matching occurs, respectively.

Testing

DIBBs Basic

1. Start up the API server by running the following command in the root directory in the CLI:

scripts/local_server.sh

2. Download the attached Patient record (bundle.json file)
3. Send the payload to the API server by running the following command:

curl -X POST --header "Content-Type: application/json" -d @bundle.json "http://localhost:8000/link-record"

The response should indicate no match was found (this is correct, since the database was empty)

4. Edit the bundle.json file to have a new UUID on line 9
5. Repeat Step 3
   The response should indicate a match was found (this is correct, since we should match the existing patient in the database)

DIBBs Enhanced

1. To test the DIBBs Enhanced algorithm, edit the bundle.json file to add a second top-level key of "use_enhanced: true" (on the same level as the "bundle" key)
2. Repeat Steps 1, 3, 4, and 5 above

Checklist

Please review and complete the following checklist before submitting your pull request:

• I have ensured that the pull request is of a manageable size, allowing it to be reviewed within a single session.
• I have reviewed my changes to ensure they are clear, concise, and well-documented.
• I have updated the documentation, if applicable.
• I have added or updated test cases to cover my changes, if applicable.
• I have minimized the number of reviewers to include only those essential for the review.
• I have notified teammates in the review thread to build awareness.

Checklist for Reviewers

Please review and complete the following checklist during the review process:

• The code follows best practices and conventions.
• The changes implement the desired functionality or fix the reported issue.
• The tests cover the new changes and pass successfully.
• Any potential edge cases or error scenarios have been considered.